最近在加裝新的compute node上去，遇到了一些問題。尚未解決。

Neutron 簡介 :

https://www.ibm.com/developerworks/cn/cloud/library/cl-openstack-neutron/index.html

可以开发一个不包含任何特定于网络的功能的、可弹性扩展的工作负载管理系统。当然，计算节点需要在彼此之间建立连接，并能访问外部世界，但它也可以利用现有的网络基础架构来分配 IP 地址和在节点之间传输数据。在多租户环境中，这样一种方法的最大问题是，已有的网络管理系统无法高效、安全地在用户之间隔离流量 — 这同时也是构建公共和私有云的组织面临的一个巨大问题。
OpenStack 解决此问题的一种方式是，构建一个详尽的网络管理堆栈，用它来处理所有网络相关请求。此方法面临的挑战是，每个实现都可能拥有一组独特的需求，包括与其他各种各样的工具和软件的集成。
OpenStack 因此采取了创建抽象层的方法，这个抽象层被称为 OpenStack Networking，可容纳大量处理与其他网络服务的集成的插件。它为云租户提供了一个应用编程接口 (API)，租户可使用它配置灵活的策略和构建复杂的网络拓扑结构 — 例如用它来支持多级 Web 应用程序。
OpenStack Networking 支持使用第三方编写插件来引入高级网络功能，比如 L2-in-L3 隧道和端到端服务质量支持。它们还可以创建网络服务，比如负载平衡、虚拟专用网或插入 OpenStack 租户网络中的防火墙。
在过去，OpenStack 的网络组件位于 OpenStack Nova (Compute) 项目中。其中大部分组件被拆分为一个包含 Folsom 版的单独项目。这个新项目最初称为 Quantum，但后来重命名为 Neutron，以避免与公司 Quantum Corporation 的任何商标混淆。所以，如果看到 OpenStack Networking 参考资料中同时出现了名称 Nova、Quantum 和 Neutron，不要感到奇怪。

模型

OpenStack Networking API 基于一个简单的模型（包含虚拟网络、子网和端口抽象）来描述网络资源。网络是一个隔离的 2 层网段，类似于物理网络世界中的虚拟 LAN (VLAN)。更具体来讲，它是为创建它的租户而保留的一个广播域，或者被显式配置为共享网段。网络也是 Neutron API 的主要目标。换句话说，端口和子网始终被分配给某个特定的网络。
子网是一组 IPv4 或 IPv6 地址以及与其有关联的配置。它是一个地址池，OpenStack 可从中向虚拟机 (VM) 分配 IP 地址。每个子网指定为一个无类别域间路由 (Classless Inter-Domain Routing) 范围，必须与一个网络相关联。除了子网之外，租户还可以指定一个网关、一个域名系统 (DNS) 名称服务器列表，以及一组主机路由。这个子网上的 VM 实例随后会自动继承该配置。
端口是一个虚拟交换机连接点。一个 VM 实例可通过此端口将它的网络适配器附加到一个虚拟网络。在创建之后，一个端口可从指定的子网收到一个固定 IP 地址。API 用户可从地址池请求一个特定的地址，或者 Neutron 可以分配一个可用的 IP 地址。OpenStack 还可以定义接口应使用的媒体访问控制地址。在取消分配该端口后，所有已分配的 IP 地址都会被释放并返回到地址池。

插件

最初的 OpenStack Compute 网络实现采用了一种基本模型，通过 Linux® VLAN 和 IP 表执行所有隔离操作。OpenStack Networking 引入了插件的概念，插件是 OpenStack Networking API 的一种后端实现。插件可使用各种不同的技术来实现逻辑 API 请求。
一些 OpenStack Networking 插件可能使用基本的 Linux VLAN 和 IP 表。这些插件对于小型和简单的网络通常已经足够，但更大型的客户可能拥有更复杂的需求，涉及到多级 Web 应用程序和多个私有网络之间的内部隔离。它们可能需要自己的 IP 地址模式（这可能与其他租户使用的地址重复）— 例如，用来允许应用程序在无需更改 IP 地址的情况下迁移到云中。在这些情况下，可能需要采用更高级的技术，比如 L2-in-L3 隧道或 OpenFlow。
插件架构使云管理员可以非常灵活地自定义网络的功能。第三方可通过 API 扩展提供额外的 API 功能，这些功能最终会成为核心 OpenStack Networking API 的一部分。
Neutron API 向用户和其他服务公开虚拟网络服务接口，但这些网络服务的实际实现位于一个插件中，插件向租户和地址管理等其他服务提供了隔离的虚拟网络。任何人都应该能够通过 Internet 访问 API 网络，而且该网络实际上可能是外部网络的一个子网。前面已经提到过，Neutron API 公开了一个网络连接模型，其中包含网络、子网和端口，但它并不实际执行工作。Neutron 插件负责与底层基础架构交互，以便依据逻辑模型而传送流量。
现在已有大量包含不同功能和性能参数的插件，而且插件数量仍在增长。目前包含以下插件：
Open vSwitch
Cisco UCS/Nexus
Linux Bridge
Nicira Network Virtualization Platform
Ryu OpenFlow Controller
NEC OpenFlow
云管理员可自行选择插件，他们可评估各个选项并根据具体的安装需求而调整它们。

架构

neutron-server 是 OpenStack Networking 服务器的主要流程。它是一个 Python 后台进程，将用户请求从 OpenStack Networking API 中继到配置的插件。OpenStack Networking 还包含 3 个代理，它们通过消息队列或标准 OpenStack Networking API 与主要 Neutron 进程交互：
neutron-dhcp-agent 向所有租户网络提供动态主机配置协议 (Dynamic Host Configuration Protocol, DHCP) 服务。
neutron-l3-agent 执行 L3/网络地址转换 (Network Address Translation) 转发，以支持网络网络访问租户网络上的 VM。
一个特定于插件的可选代理 (neutron-*-agent) 在每个虚拟机管理程序上执行本地虚拟交换机配置。
一定要知道 OpenStack Networking 与其他 OpenStack 组件之间的交互方式。与其他 OpenStack 项目一样，OpenStack Dashboard (Horizon) 提供了图形用户界面，以便管理员和租户用户能够访问功能 — 在这里，是访问用来创建和管理网络服务的功能。这些服务也依照 OpenStack Identity (Keystone) 对所有 API 请求执行身份验证和授权。
与 OpenStack Compute (Nova) 的集成更加特殊。Nova 启动了一个虚拟实例时，该服务会与 OpenStack Networking 通信，将每个虚拟网络接口插入到一个特定的端口中。